A typical mainframe system consists of multiple client terminals accessing a mainframe server. At given time, a plurality of tasks is running on the mainframe system. The tasks can be initiated, destroyed, or modified via one of the client terminals.
An exception is an error condition that changes the normal flow of control in a program, or task. An exception may be generated (“raised”) by hardware or software. Hardware exceptions include reset, interrupt or a signal from a memory management unit. Exceptions may be generated by the arithmetic logic unit or floating-point unit for numerical errors such as divide by zero, overflow or underflow, or instruction decoding errors such as privileged, reserved, trap or undefined instructions. Software exceptions are even more varied and the term could be applied to any kind of error checking which alters the normal behavior of the program.
When an exception occurs within a task running on a mainframe, the task may become suspended. In order for the task to resume, operation intervention is required. Operation intervention is also required for circumstances where tasks become suspended, but no exception occurs. For example, if a task requires the addition of a file from a particular tape or drive, the task will wait until the required file is provided. Although no actual error occurred within the code or hardware running the task, the task still becomes suspended, and requires operator intervention.
Because mainframe systems can run multiple tasks at the same time, it is possible for more than one task to become suspended at a given time. Some of the tasks may have encountered exceptions, while other tasks may have been suspended for reasons other than exceptions. Thus, the need arises for handling multiple program exceptions within a mainframe environment, or within other heterogeneous systems.
One prior art method to which the method of the present invention generally relates is described in U.S. Pat. No. 5,892,945 entitled METHOD AND APPARATUS FOR DISTRIBUTING WORK GRANULES AMONG PROCESSES BASED ON THE LOCATION OF DATA ACCESSED IN THE WORK GRANULES. This prior art reference is a method and apparatus for distributing work granules of a parent task among processes running on various nodes in a multi-processing computer system. The parent task is divided into work granules of varying sizes based on the location of the data that must be accessed to perform the work granules. At least one process on each of the nodes that will be assisting in the execution of the parent task is initially assigned a work granule based on efficiency considerations. Such efficiency considerations may include, for example, the location of the data to be accessed relative to the process, the current I/O load of the devices on which data to be accessed is stored, and the relative sizes of the various work granules. When a process completes the work granule assigned to it, the process is assigned one of the remaining unassigned work granules. Again the work granule assignment is made based on efficiency considerations. This process continues until all of the work granules have been completed.
The present invention differs from the prior art in U.S. Pat. No. 5,892,945 in that the present invention is does not deal with distributing work from a parent task to children tasks. Instead, the present invention communicates between the task on a host and the task on a client. When a task on a host is suspended by the operating system, the present invention enables the task on a host to communicate with the task on a client PC interactively.
Another prior art method to which the method of the present invention generally relates is detailed in U.S. Pat. No. 6,182,243 entitled SELECTIVE DATA CAPTURE FOR SOFTWARE EXCEPTION CONDITIONS. This prior art reference, a selective data capture method for software exception conditions in the operation of a data processing system, includes steps for describing the pertinent data to collect before loss of control of the faulty program occurs. First the program preventively declares in a table all the data to capture in case of error (501). In a second stage, at the key points of the code, the pertinent sets of data in the table are activated (502). On the occurrence of an error (503), only the data previously declared and activated are collected (504) by the external code in charge of managing the error reporting to a maintenance subsystem (505). The art of U.S. Pat. No. 6,182,243 is attached to a global data capture strategy, particularly to an Error Notification and Selective Dump processes.
The present invention differs from the U.S. Pat. No. 6,182,243 in that error exceptions are only an ancillary part of the present invention. The present invention additionally addresses the need for system resources such as extra disk space or a new tape media. The prior technique, on the other hand, solely relates to capturing data before a program fault, and returning the captured data to the appropriate caller.
Another prior art method to which the method of the present invention generally relates is detailed in U.S. Pat. No. 5,923,863 entitled SOFTWARE MECHANISM FOR ACCURATELY HANDLING EXCEPTIONS GENERATED BY INSTRUCTIONS SCHEDULED SPECULATIVELY DUE TO BRANCH ELIMINATION. This prior art reference describes methods for handling exceptions caused by speculatively scheduled instructions or predicated instructions executed within a computer program. The method for speculatively scheduled instructions includes checking (at a commit point of a speculatively scheduled instruction), a semaphore associated with the speculatively scheduled instruction and branching to an error handling routine if the semaphore is set. A set semaphore indicates that an exception occurred when the speculatively scheduled instruction was executed. For a predicated instruction the method includes checking a predicate of an eliminated branch and a semaphore associated with the speculative instruction at a commit point of the speculative instruction and branching to an error handling routine if the semaphore indicates that an exception occurred when said speculative instruction was executed, and the predicate is true, which indicates that said speculative instruction was properly executed.
The present invention differs from U.S. Pat. No. 5,923,863 in that the present invention does not deal with “SPECULATIVE” perdition of program behavior. Instead, the present invention deals with the interactive communication between a client task and a host task, should the host task be suspended by the operating system.
Yet another prior art method to which the method of the present invention generally relates is detailed in U.S. Pat. No. 5,815,708 entitled METHOD AND APPARATUS FOR DYNAMICALLY LOADING METHOD CALL EXCEPTION CODE IN RESPONSE TO A SOFTWARE METHOD EXCEPTION GENERATED IN A CLIENT/SERVER COMPUTER SYSTEM. This prior art reference describes a method for handling method calls in a client/server computer system, and includes the step of receiving, at a server computer, a method call generated by a client computer. The server computer then attempts to execute the method call and subsequently generates an exception. The exception is passed to the client computer. The client computer matches the exception to exceptions in an exception list stored in the client computer to obtain an exception object identifier. The exception object identifier is used to load exception code into the client computer. The exception code is then processed. Thus, the exception code need not be loaded at the time of generating the method call. Instead, it is only loaded when it is required at run time.
The prior art reference of U.S. Pat. No. 5,815,708 differs from the method of the present invention in that this prior art deals with loading an exception handling procedure dynamically should an exception happen during program execution. The present invention, on the other hand, relates to interactive communication between a client task and a host task should the host task be suspended by the operating system.
Yet another prior art method to which the method of the present invention generally relates is detailed in U.S. Pat. No. 5,815,702 entitled METHOD AND SOFTWARE PRODUCTS FOR CONTINUED APPLICATION EXECUTION AFTER GENERATION OF FATAL EXCEPTIONS. This prior art reference describes a method of operating a computer and a software product, by enabling a computer system and application to continue execution after the application has generated a fatal exception. This allows the user to save any data file that was being used at the time the fatal exception was generated, and thereby not lose that data that would have otherwise been lost by the operating system spontaneously terminating the application because of the fatal exception. The method involves receiving a notification that the application has generated an exception, notifying the operating system that the exception has been handled, so as to “fool” the operating system and prevent it from spontaneously terminating the application, and then to enable the application to continue operating so that the user can save any unsaved data by executing a continuous loop of code in place of the main message loop of the faulting application. The continuous loop receives messages and events for the application and passes them to the proper executable components of the application. This software product includes an exception handler that receives notification from the operating system of the fatal exception, a background process that is notified by the exception handler of this occurrence and that prompts the user with an option to terminate or continue the application, and a continuous loop of code instructions that replaces a message loop of the application, thereby enabling it to continue execution.
The method of U.S. Pat. No. 5,815,702 differs from the present invention in that this prior art handles fatal exceptions. The present invention, on the other hand, handles both fatal and non-fatal exceptions. The majority of exceptions handled by the present invention result from the normal execution of a program.